Is there a reason why one of these should work and the other should give a type error?
x + x * y + 5
5 + x * y + x

@lkstrp I went down a bit of a rabbit hole with the typing in order to make sure the type checker could tell the difference between a LinearExpression and QuadraticExpression which involved breaking the inheritance between the two and making a base class. Could you please have another look?

impressive work @RobbieKiwi ! @lkstrp or I will go through it soon! we'll make another release today but this will definitely go into the next one!

@RobbieKiwi do you remember why the merge function now requires a cls argument? I recon that it is a bit inconvenient for users...

@RobbieKiwi do you remember why the merge function now requires a cls argument? I recon that it is a bit inconvenient for users...

@FabianHofmann Now that LinearExpression and QuadraticExpression are separated this function would need some generic type matching to properly return the right type without mypy complaining. Expressing this just using the input expressions is impossible because of the complicated combination (LinearExpression + QuadraticExpression -> QuadraticExpression). Instead I opted for matching the type on the passed cls.

The cls is still an optional parameter. If you don't pass it then you get mypy warnings in the CI pipeline and runtime warnings.
If you like I could have another look at it and find a way to get rid of the runtime warning?

thanks @RobbieKiwi ! that makes sense. atm we are just getting quite some deprecation warnings as we have not set the cls argument and I was wondering whether we couldn't do some sort of auto-detection like for example in pd.concat where you also can pass a series or dataframe. but it feels this won't be compatible with mypy.
if you have a some spare time to think about how we could get rid of the runtime warning, that would be great. perhaps we could also just set the default of cls to LinearExpression?